1. Field of the Invention
The present invention relates generally to an improved data processing system and in particular to a computer implemented method and apparatus for in-lining Java™ subroutines. (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.) Still more particularly, the present invention relates to a computer implemented method, apparatus, and computer usable program code for in-lining Java subroutines on a target device at load time.
2. Description of the Related Art
Java is an object-oriented programming language and environment focusing on defining data as objects and the methods that may be applied to those objects. The Java virtual machine (JVM) is a virtual computer component that resides only in memory. The JVM allows Java programs to be executed on different platforms as opposed to only the one platform for which the code was compiled. The Java virtual machine prescribes support for subroutines. Subroutines are used by Java compilers when a section of code must be executed from two or more paths in a particular method. In particular, Java compilers typically use subroutines to implement constructs, such as the finally clause of a ‘try . . . finally . . . ’ construct. Subroutines are implemented using any number of bytecodes, such as JSR, JSR_W, RET, and WIDE RET.
Unfortunately, subroutines contribute a significant amount of complexity to a Java virtual machine implementation. Areas of complexity include bytecode verification, Just-In-Time (JIT) compilation, and particularly liveness mapping for garbage collection. Subroutines make the flow analysis required for precise identification of object references very difficult, or in some cases, impossible.
In many cases, there are additional problems because subroutines from the subset of Java may not be supported on all devices, and newer versions of Java may only support subroutines for backwards compatibility or may not support subroutines at all. These problems cause difficulty because legacy applications will continue to use subroutines for the foreseeable future. One solution requires the Java virtual machine to have full support for subroutines which requires extensive memory and processing requirements. In another solution, applications must be run through a preprocessor using a separate application authoring-time system which removes JSR, JSR_W, RET, and WIDE RET bytecodes and in-lines the subroutines into each place where the subroutines are called. This process requires an additional build step and is not acceptable for many editions of Java used by various organizations.